packages/api/
  server/
    security.mts          +134/-0    origin allowlist, cors opts, verifyClient, bindHost
    http.mts              +28/-46    global cors + verifyOrigin, drop 41 per-route calls
    ws-client.mts         +11/-0     close disallowed origins as a backstop
  test/
    security.test.mts     +97/-0     12 tests
  dev-server.mts          +5/-3      bind host, verifyClient
  index.mts               +2/-1      export bindHost, webSocketServerOptions
srcbook/src/
  server.mts              +18/-6     bind host + warn, guard process.send
docker-compose.yml        +5/-1      HOST=0.0.0.0 inside container, explain why
turbo.json                +2/-0      declare HOST, SRCBOOK_ALLOWED_ORIGINS
tasks/0001-...md          +22/-1     close, record findings
.changeset/               +19/-0

Stacked on #506. Closes task 0001.

Srcbook has no authentication and executes arbitrary code, so the request origin is the only thing separating the user's own tab from any other page they have open. Nothing was checking it.

What was possible before this

Verified against a running instance, not theorized:

The websocket is what makes this remote code execution rather than disclosure: a page lists sessions over HTTP, writes a cell, runs it. No interaction beyond visiting the page.

What changed

New server/security.mts owns the allowlist — local origins on any port, plus anything in SRCBOOK_ALLOWED_ORIGINS. Both the HTTP and websocket paths use it, so they can't drift.

HTTP. The 41 per-route cors() calls collapse into one cors + verifyOrigin pair on the router. Disallowed origins get a 403, not just a missing CORS header — CORS alone stops an attacker reading a response, but the request still executes, which is all you need for POST /api/settings.

WebSocket. Origin is checked in verifyClient, before the handshake. I first put the check in the connection handler and confirmed it's too late: the server logged the rejection, but the client still saw open fire and only afterwards got closed. verifyClient gives a 401 at the handshake and no socket at all.

Bind. 127.0.0.1 unless HOST says otherwise, with a warning when it doesn't. This makes docker-compose's HOST variable real — it was previously read by nothing, while reading as though it controlled exposure. Compose now sets HOST=0.0.0.0, because Docker forwards published ports to the container IP; host-side exposure stays controlled by HOST_BIND, which already defaulted to loopback.

Bonus. Guarded process.send in the CLI server — it only exists under IPC, so node dist/src/server.mjs crashed immediately after printing running at http://localhost:2150. Found while testing the bind change; it's one line and in a file this PR already touches.

Verification

Re-ran the original attacks against the patched build:

foreign origin  → HTTP 403 / websocket 401 at handshake
localhost:2150  → HTTP 200 / websocket connects        (the app)
localhost:5173  → HTTP 200 / websocket connects        (vite dev)
no Origin       → HTTP 200 / websocket connects        (CLI, curl)
bind            → TCP 127.0.0.1:2150 (was TCP *:2150)

12 new tests for the allowlist, including the substring cases that make this kind of check go wrong (localhost.evil.com, example.com.evil.com). Suite is 23 tests, up from 11. Build, lint, and format all pass.

Compatibility

Anyone deliberately reaching Srcbook from another machine now needs HOST plus their origin in SRCBOOK_ALLOWED_ORIGINS. That's a real behavior change, hence minor in the changeset, and the whole point — it was previously open to the network by default.

Not covered here — task 0002, next in the stack: path traversal in DELETE /api/srcbooks/:id, shell injection via cell filenames, containing POST /api/file to SRCBOOKS_DIR, and validating the settings body.

🤖 Generated with Claude Code